앞에서 나온 여러 장을 통해서 우리는 분석,설계를 위한 여러가지 도구와 기법을 배웠다.
하지만 고객은 객체지향원리나 다이어그램 따위에는 신경쓰지 않으며, 단지 자신이 요청한 소프트웨어가 의도한 대로 작동하기만을 바란다.
그리고 잘 진행되고 있다는 것을 문서가 아닌, 컴퓨터에서 돌아가고 있는 어플리케이션으로 보기를 원한다.
그러므로 우리는 한번에 전체의 어플리케이션을 보여줄 수 는 없지만, 고객이 안심할 수 있도록 보여줄 수 있는 부분을 구현을 하며, 부분구현의 반복작업을 통해 전체의 어플리케이션을 완성한다.
이러한 반복작업은 두가지의 기본적인 접근 방식이 있다.
어플리케이션의 특정한 특징을 선택하고, 완성될때까지 그 특징을 계획, 분석, 개발하는 것.
한번에 하나의 특징을 작업하고 그리고 나서 반복하여, 어플리케이션의 기능을 완성할 때까지 한번에 하나씩 특징들을 구현한다.
유스케이스의 시나리오를 선택하여 시나리오가 완성될 때까지 코드를 작성하는 것.
유스케이스 내에서 하나의 시나리오를 완성하는 작업을 한다. 그 다음 또 다른 시나리오를 선택하여 작업하며, 유스케이스느이 모든 시나리오가 완성될 때까지 반복한다. 그리고 나서, 다음 유스케이스를 선택하여 위의 작업을 하며, 모든 유스케이스가 작동할 때까지 반복한다.
| 특징 주도 개발 | 유스케이스 주도 개발 |
|---|---|
|
|
| 게리의 게임시스템 프레임웍 특징 리스트 |
|---|
|
게리의 비전 기술서를 통해 게리가 프레임웍 내의 유닛들에게 바라는 기능에 대해서 제안
| Unit |
|---|
| type:String propertes:Map |
| setType(String) getType():String setProperty(String, Object) getProperty(String):Object |
고객은 스스로 납득할만한 무언가를 보고 싶어한다. 그러므로 클래스 다이어그램으로 고객을 납득시키기에는 무리가 있으므로, 우리는 고객에게 보여줄 테스트 시나리오늘 제시할 필요가 있다.
이렇게 하는 것은 우리가 작성한 코드가 작동된다는 것과 고객이 원하는대로 동작한다는 것을 입증하는 길이다.
테스트케이스가 복잡할 필요는 없으며, 단지 고객에게 클래스의 기능이 정확하게 동작하고 있다는 것을 보여주면된다.
유닛의 속성에 대해서, 하나의 유닛을 생성하고 유닛에 속성하나를 추가하는 간단한 테스트 시나리오 작성
테스트 케이스
자신의 소프트웨어를 생각할 수 있는 모든 가능한 방법으로 테스트 해야함. 소프트웨어의 잘못된 사용방법에 대해서도 테스트 해야 함.
Unit 클래스의 속성을 모든 유닛이 가질수 있는 속성과 특정 타입의 유닛들만 가질수 있는 속성으로 분리하여 클래스의 변경계획 세우기
유닛의 공통속성들은 속성 Map 밖으로 빼내고, 변하는 속성은 Map안에 남겨둔다.
| Unit |
|---|
| type:String propertes:Map {color:red}id:int name:String weapons:Weapon *{color} |
| setType(String) getType():String setProperty(String, Object) getProperty(String):Object {color:red}getId():int setName(String) getName():String addWeapon(Weapon) getWeapons():Weapon * {color} |
Trade Off
모든 종류의 유닛 속성들을 모두 캡슐화하여 속성 Map에 저장한다.
| Unit |
|---|
propertes:Map |
setProperty(String, Object) getProperty(String):Object |
Trade Off
약정에 의해 프로그램을 작성할 때 당신과 당신의 프로그램 사용자는 소프트웨어가 어떤 방식으로 동작할 것이라는 것에 동의하고 있는 것이다.
고객이 어떠한 일이 발생되기를 원하건 간에 고객이 안전한 응답을 얻도록 확인